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SERVICE 

CROSS-REFERENCES TO RELATED APPLICATIONS 
5 [0001] This application is a divisional application of U.S. Patent Application Serial No. 
09/354,904, filed July 16, 1999, entitled "System and Method for Managing Prepaid Wireless 
System;" which claims priority from U.S. Provisional Application No. 60/093,000, filed July 
16, 1998, entitled "System and Method for Managing Prepaid Wireless System," the 
disclosures of which are hereby incorporated by reference. 

10 

FIELD OF INVENTION 
[0002] The present invention relates to system and method for managing a prepaid wireless 
service. 

1 5 BACKGROUND OF THE INVENTION 

[0003] In a conventional wireless system, a subscriber purchases a wireless phone (i.e., a 
handset) and a wireless service from a service provider. The subscriber has a contract with 
the service provider and pays a monthly subscriber fee for access to the wireless service and 
also pays for air time. If the subscriber fails to timely pay, the service provider may 

20 disconnect the service. Then the service provider have to attempt to collect money for unpaid 
bills. 

[0004] U.S. Patent No. 5,470,247 describes a cellular telephone communication refill 
system. This system includes an apparatus that meters payment according to a predetermined 
parameter (e.g., a number of calls, an amount of funds, etc.). The predetermined parameter is 

25 stored within a secured metering device of the apparatus. 

[0005] U.S. Patent No. 5,577,100 describes a mobile phone having internal accounting 
capabilities for real time call debiting. The mobility phone includes an internal memory 
which stores an upgradeable rate table and a complex billing algorithm calculating an account 
status on the fly. In addition, the mobile phone is capable of alerting a customer of real time 

30 account status. Furthermore, this U.S. Patent provides for a communication system which 
activates the mobile phone and upgrades the account status in the rate table over airways. 

1 



[0006] Therefore, there is a need for a wireless prepaid system where the service provider 
does not need to be concerned with collecting the unpaid bills and where the subscriber has 
control over his wireless expenditures. 



5 BRIEF SUMMARY OF THE INVENTION 

[0007] The present invention provides a technique for facilitating provisioning of pre paid 
wireless communication services. In accordance with an embodiment of the present 
invention a wireless device includes a memory that stores a credit amount and a tariff or rate 
table. The credit amount can be set at the time the device is activated. The device monitors 

10 the credit available and recalculates that amount as the device is used. The recalculation uses 
information stored in the tariff or rate table. In the event the subscriber needs to refresh the 
available credit he or she contacts the service provider and provides either credit or debit 
account information and/or prepaid calling card information to an IVR system or to an agent 
in a call center environment. The provider then generates an SMS message to modify the 

15 credit contents of the devices memory over the air. Furthermore, the provider may provide a 
plurality of alternative tariff or rate tables, and/or may modify such tables over time. The 
provider can use SMS messages to update the device's memory to include an alternative tariff 
or rate table. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] Figure 1 shows an exemplary embodiment of a system according to the present 
invention. 

[0009] Figure 2 shows an exemplary embodiment of a wireless prepaid device according to 
the present invention. 

25 [0010] Figure 3 shows a diagram illustrating a short message service process. 

[0011] Figure 4 shows an exemplary embodiment of a software model of processing 
queues. 

[0012] Figure 5 shows a flow chart illustrating carrying out an activation process. 
[0013] Figure 6 shows a flow chart illustrating a process for refreshing an available credit 
30 amount. 

[0014] Figure 7 shows a process flow relating to a credit refresh operations using an 
Interactive Voice Response System. 

[0015] Figure 8 shows another process flow relating to credit refresh operations using 
customer service agents. 
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[0016] Figure 9 shows agents 1 application developed as a thin client. 
[0017] Figure 10 shows a modification of Figure 9. 

DETAILED DESCRIPTION OF THE INVENTION 
5 General Overview of System 1 

[0018] In a system in accordance with the present invention for managing a wireless 
prepaid service, a network provider delivers a wireless communications network, e.g., Global 
System for Mobile Communications (GSM) network. The present invention is just as 
applicable to alternative wireless communication networks as it is to GSM. A service 
10 provider, on the other hand, provides a prepaid service which includes delivering customer 
service functions to a subscriber of such services. 

[0019] Figure 1 shows an exemplary embodiment of the system 1 in accordance with the 
present invention. The system 1 includes a combination of networked workstations and 
servers that are described below. Connections within the system 1, except as otherwise 
15 indicated, are made via, e.g., Ethernet Transmission Control Protocol/Internet Protocol 

(TCP/IP) 141 . Alternative data networking arrangements may be provided to transfer data 
throughout the system. 

[0020] The system 1 is accessible via a wireless device 10 (e.g., a mobile phone), a fixed 
phone 150 or a communication network (e.g., the Internet) (not shown). Using the device 10, 

20 the subscriber is connected to a Fixed Public Phone Network (FPPN)140, via a wireless 

network; the phone 150 is connected to the FPPN 140 directly. The FPPN 140 then connects 
the subscriber, via a suitable telephony interface, e.g., Digital Access Signaling System 
(DASS) 143, to an Automatic Call Distribution (ACD) system 130. 
[0021] The ACD 130 may connect the subscriber to an automated Interactive Voice 

25 Response (IVR) system 30 via a suitable telephony interface, e.g., Digital Private Network 
Signaling System (DPNSS) 142 or to a Call Center 165 having customer service agents. The 
subscriber may switch between the IVR 30 and the Call Center 165 at any time during the 
call. 

30 Device 10 

[0022] Figure 2 illustrates in more detail the wireless device 10 of the system 1. The 
device 10 can be, e.g., a wireless phone, a wireless pager, or an apparatus having a wireless 
modem. The device 10 includes a memory device 1 1, a processor 12, a receiver/transmitter 
13, an input device 14 and an output device 15. The input device 14 can be, e.g., a keyboard, 
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a voice recognition device, etc. The output device 15 can be, e.g., a LCD screen, a display, a 
monitor, a sound device, etc. The memory device 1 1 may store, e.g., software applications, a 
subscriber profile, calling tariff tables, an unique identification number (in this embodiment 
of the invention the MSISDN of the wireless phone subscriber) and an available credit 
5 amount. The memory device 1 1 also stores a preprogrammed number which allows the 

subscriber to connect with the system 1 to be activated and/or to replenish the credit amount. 
[0023] Calls to and from the device 10 invoke call charging based on the calling tariff 
tables stored in the memory device 1 1 . For each call received or initiated, the device 10 
calculates its cost using the tariff or rate tables stored in the memory, and deducts the cost 

10 from the available credit amount. 

[0024] Certain data (e.g., the preprogrammed number and MSISDN) of the memory device 
1 1 are stored during an assembly process of the device 10 by a manufacturer. The 
manufacturer provides this data, e.g., as a data file, to the service provider. The service 
provider needs the data file to perform an initial provisioning of the device 10 on the wireless 

15 network. The file is initially stored in a Customer Support System (CSS) 50 (described in 
detail below). At a predetermined time, the data file is transferred to a Network Billing and 
Administration System (NBAS) 190 and an encryption and authorization server 40 
(hereinafter EAS) such as the Debit Authorization Server (DAS) from Telemac Cellular 
Corporation. These data file transfers and processing are performed before any use can be 

20 made of the device 10. 

[0025] The device 10 is capable of receiving and sending information using Short Message 
Service (SMS) messages. Security of the SMS messages is provided by an encryption server, 
e.g., EAS 40. The EAS 40 ensures that the SMS messages cannot be reused, copied, viewed 
or altered. The EAS 40 encrypts the information in the SMS messages (e.g., the MSISDN, 

25 credit refresh, SIM Serial Number (SSN) and a message serial number for this encryption of 
the SMS message). The EAS 40 passes the SMS message to the IVR 30 which then sends 
the SMS message to the device 10 (See Figure 1). 

[0026] Figure 3 illustrates a diagram of a Short Message Service Process. The system 1 
implements an SMS Center (SMSC) 180 (in Figure 1) that supports an appropriate two way 
30 protocol over, e.g., the TCP/IP transport connection. A Short Message Service Mobil 

Terminated (SMS MT) message containing predetermined information is sent over the air to 
the device 10. The device 10 receives the SMS messages using the receiver/transmitter 13 
(Figure 2), decrypts the SMS MT message and performs the required operation (e.g., a credit 
refresh). Then, the device 10 sends a positive acknowledgment in the form of a Short 
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Message Service Mobile Originated (SMS MO) message back using the receiver/transmitter 
13. The SMS MO messages from the device 10 to the system 1 are not charged to the 
subscriber. 

[0027] The IVR 30 manages an SMS work queue 300, including an application level flow 
5 control, retry counts, monitoring and auditing. The IVR SMS Send Task (SMS TX) 310 
monitors the SMS work queue 300, processes new entries accordingly, monitors MT ACK 
messages returned from the SMSC 180 (which can be SMSC A 330 and SMSC B 340) and 
updates the status in the SMS work queue 300. 

[0028] The IVR SMS Receive Task (SMS RX) 320 monitors the MO ACK from the 
10 devices 10, by whatever route they arrive (i.e., the SMSC A 330 or the SMSC B 340), links 
them with the appropriate SMS MT message, and then updates the SMS work queue 300 as 
well as stores any data returned with the SMS MO message. 

CSS 50 

15 [0029] The CSS 50, shown in Figure 1, includes a subscriber database 230 and a scratch 
card (i.e., a prepaid calling card) database 240. The subscriber database 230 continuously 
keeps track of all activities conducted by the subscriber, the IVR 30 and/or the Call Center 
165 (e.g., activation, credit refresh, and device 10 activities). In addition, the subscriber 
database 230 automatically mirrors the information stored in the memory device 1 1 of the 

20 device 10. The subscriber database 230 is used to resolve disputes with the subscriber and to 
detect possible fraud. 

[0030] The scratch card database 240, on the other hand, tracks all activities of a scratch 
card (e.g., generation, printing, distribution, activation and use of the scratch card). In one 
embodiment, the subscriber and scratch card databases 230, 240 are run and maintained 
25 using, Microsoft SQL Server® from Microsoft Corporation. Further, in one embodiment, a 
CSS application software on CSS 50 runs under, Microsoft Windows NT® Version 4 from 
Microsoft Corporation. 

SOFTWARE MODEL 

30 [0031] The system 1 according to one embodiment the present invention utilizes a software 
model of f work queues'. An exemplary embodiment of the software model is shown in 
Figure 4. A process includes a number of separate and discrete subprocesses; each 
subprocess can be managed by a single task. For example, an input queue 400 provides 
information about a task 1 which is necessary to perform the subprocess 410. The subprocess 
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410 processes the information in accordance with a definition of the process and then places 
results in an output queue 420. The output queue 420 for the subprocess 410 then becomes 
an input queue 420 for a subprocess 430, within the definition of the process. The input 
queue 420 provides information about a task 2 to the subprocess 430 and then the results are 
5 placed in an output queue 440. The queue 440 serves as the output queue for the subprocess 
430 and also as an input queue for a subprocess 450. If for some reason any task stops, the 
input queue processes grow, and the output queue gradually diminishes to an empty queue, as 
the other subprocesses ahead in a production line continue to work. If the input queue grows 
at a rate greater than the rate a task can process it, additional occurrences of the same task can 
10 be started. 

[0032] In one embodiment, the software model, shown in Figure 4, is applied to the credit 
refresh process described below, where separate processes exist for credit/debit card 
validation, the EAS processing, and the SMS messages sending. This software model is 
suited to applications where a number of specialized processes are required. The software 

15 model also facilitates easy adaptation into other environments where interfaces change. 

There is no need to change an entire application, only the subapplication that performs that 
process. This approach also speeds up integration testing, as each subapplication can be 
completely tested in isolation to the other sub applications. Additionally, the processes that 
put work into the queues are not only the IVR 30 processes; they are also personal computer 

20 based applications deployed in the Call Center 165. 

Activation 

[0033] Figure 5 provides a flow chart illustrating a process for activating wireless device 
10. When the subscriber dials the preprogrammed number, the call is routed to and answered 
25 by IVR 30(step 500). Alternatively, the subscriber may activate the device 10 by calling the 
Call Center 165 (described in detail below). To activate the device 10, the IVR 30 uses 
device 10's MSISDN. 

[0034] The IVR 30 responds differently to calls received from the device 10 for the first 
time, a registered device 10, a non registered device 10, the fixed phone 150 or the 
30 communication network. 

[0035] When the call is received by the IVR 30, the IVR 30, using its Digital Signal 
Processing (DSP) input recognition capability, analyzes an A party number (i.e., a number of 
calling party or a call originator) to determine automatically the MSISDN as the DSP input 
(step 510). If the subscriber uses any means other than the device 10 to connect to the system 
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1, the IVR 30, prompts the subscriber to enter manually the appropriate MSISDN as a DTMF 
input (step 520). 

[0036] Subsequently, the system 1 determines whether the MSISDN is valid using the 
subscriber database 230 (step 530). If the MSISDN is invalid, the system 1 rejects the call or 
5 requests the subscriber to reenter the MSISDN (step 550). If the MSISDN is valid (step 540) 
(i.e., had been already provisioned to be used within the system 1), the system 1 then checks 
if the mobile device has already been activated referring to its MSISDN (step 560). As 
described above, the device 10 cannot be activated without prior provisioning. If the 
MSISDN was not activated before (i.e., its a non registered device 10), the system 1 activates 
10 it by unbarring (step 570) and then sends the subscriber to the credit refresh process (step 
580). The subscriber is also sent to the credit refresh if the IVR 30 determines that the 
MSISDN was activated previously. Subsequently, the IVR 30 updates the subscriber 
database 230. 

[0037] The "activated ?" step can include a substep of checking whether a bar was placed 

15 on the device 10 (not shown). If the device 10 is barred, then a further check is made to 
establish whether the bar is in place as a result of the agents' request (e.g., because the 
associated device 10 was stolen). If this is not the case, then the IVR 30 records that the 
device 10 is not active by setting an internal flag, but it can be activated and unbarred as 
described. If however, it was barred at an agent's request further processing may be inhibited. 

20 [0038] Once activation of the device 10 and the credit refresh (described below) have been 
successfully processed, the IVR 30 instructs the CSS 50 to unbar the associated MSISDN. 
The CSS 50 then interfaces with the Gateway 191 to remove the incoming call bar and thus 
enable incoming SMS messages and telephone calls to the device 10. Due to the NBAS 190 
unavailability for a routine maintenance, activation of the device 10 might be limited to be 

25 performed only between certain hours of the day. This is because the responses from the 

NBAS 190 that the system 1 needs to complete the unbar process may not be delivered until 
several hours have elapsed from submission of the unbar requests. The IVR 30 may advise 
the subscriber as to this availability, and prevent the activation with an appropriate message. 
In such cases the CSS 50 queues requests and only sends them to the NBAS 190 when it is on 

30 line. After sending a provisioning request to the NBAS 190, the CSS 50 polls for an 

acknowledgment that the request has been acted on. The CSS 50 maintains flags in the 
subscriber database 230 that indicate the current status of the subscriber (via the MSISDN). 
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[0039] Within the activation component, the CSS 50 un bars the device 10 via the NBAS 
190 interface to a Home Location Register (HLR) 260 within the system 1 (shown in Figure 
1). The HLR 260 has a HLR database 270. 

[0040] At the time of activation, the service provider can use the SMS service described 
5 below to provide tariff table information to the device over the air. Updates of this tariff table 
can be sent whenever a subscriber seeks to refresh the credit of the wireless device as 
described below. Alternatively, the service provider can initiate an SMS message that 
forwards tariff table updates at any time the service provider needs to do so. This enables the 
service provider to have maximum flexibility in establishing its tariff rates, especially as 
10 network providers become more competitive in price structures offering alternative rate 
packages to capture as many different users, having different usage patterns, as possible. 

Credit Refresh 

[0041] Figure 6 provides a flow chart that illustrates the credit refresh process (i.e. 9 

15 increasing the available credit amount). The subscriber accesses the IVR 30 by calling the 

preprogrammed number using the wireless device 10, the telephone 150 or via a data network 
such as the Internet. The system permits the subscriber to call the preprogrammed number, 
even though the available credit amount on the device 10 may have fallen below a required 
amount needed to make an outbound call. 

20 [0042] When the preprogrammed number is called, the IVR 30 answers the call (step 600) 
and launches its application, similar to one used for the activation of the device 10. The IVR 
30 collects and validates information about the device 10 (i.e., the MSISDN) (step 610). To 
increase the available credit amount, the subscriber may use (step 620) a credit/debit card 
and/or a scratch card (described in more detail below). In a single phone call, the subscriber 

25 may increase the available credit amount (step 660) for more than one device 10 and may use 
more than one credit/debit card, scratch card, or any combination of the above cards. 
[0043] Once the scratch card has been authorized (step 650), or the credit/debit card 
information collected (step 640), and if the subscriber has no further operations to perform, 
the call will be terminated (step 670). 

30 [0044] Figure 7 illustrates a process flow relating to the credit refresh. The IVR 30 may 
queue the requests for background processing. As the scratch card has been authorized on 
line during the call the requests may be queued for processing by the EAS 40. (See blocks 
700, 720). The credit/debit card information must first be authorized through the Payment 
Clearing Service (PCS) 200 (block 700 to block 710, to block 730 to block 720). 



[0045] An encryption process can interface with the EAS 40 using, e.g., the TCP/IP socket 
socket protocol. The process will send the MSISDN and Credit Update Value pair (block 
720) to the EAS 40. The EAS 40 returns the encrypted SMS message (block 740) to be sent 
to the device 10. It may also return other SMS messages that have been stored (e.g., requests 
5 to change the calling tariff tables, requests to check the available credit amount). The EAS 
40 normally sends information back to the IVR 30 at the time of the credit refresh, but 
information can be sent on an ad hoc basis. All processed EAS requests are placed in a queue 
awaiting (block 750) to be sent by the SMS message to the device 10. Detailed records for 
each process are recorded for future audit. 

10 [0046] The SMS send process handles the delivery of the SMS messages to their intended 
destination (block 760). As described above in Figure 3, the device 10 generates a return 
SMS MO message in response to the SMS MT messages. The SMS process monitors bi 
directional SMS messages and only mark a message as processed once a successful return 
SMS MO message has been received. More particularly, the SMS process handles the 

15 delivery of the SMS messages via the SMSC 180 to their intended destination. The SMSC 
180 returns a low level ack, then the device 10 returns an ack. The device 10 then returns a 
higher level ack for credit refresh, when the credit refresh has taken place in the device 10. 
This SMSMO may not be subjected to change. If no SMS MO message is received within a 
predetermined timeout, the SMSC 180 returns the SMS message to the IVR 30. Depending 

20 on the failure code in the message, the IVR 30 can choose to re transmit the credit refresh 
SMS message. 

Credit/Debit Card Authorization 

[0047] Specifics as to implementations for the credit/debit card are described below. Due 
25 to the possible delay in authorization of the credit/debit card transaction, this process may be 
performed after the IVR 30 interaction with the subscriber has terminated (step 670). Before 
the call termination, the subscriber is advised that the available credit amount will be 
updated; thus, the device 10 should be kept switched on. If the device 10 is turned off, the 
available credit amount will be updated as soon as the subscriber turns on the device 10. 
30 [0048] The payment by the credit/debit card requires that the subscriber enter certain 
information about the credit/debit card. This information includes a card number, an 
expiration date, an issue number (only for certain types of the debit card), and a desired 
amount. This information is stored in the credit/debit card queue for transaction authorization 
(block 710). The process to be performed for the credit/debit card authorization consists of 
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assembling the relevant card information collected from the subscriber in accordance with 
that required for the input drive on the PCS 200, and then sending this data to an acquirer 
(e.g., an institution that provided the credit/debit card) (block 730). 
[0049] Payment clearing processing uses the PCS 200 and involves, e.g., the following 
5 elements: the subscriber, a card issuer, a merchant and the merchant's transaction acquirer 
(the acquirer). In one exemplary embodiment, on line requests for payment authorization are 
submitted by the merchant to the acquirer using protocols defined by the U.K. Association 
for Payment Clearing Services (APACS) Standards. The acquirer forwards the request to the 
issuer and returns the response to the merchant. Daily batches of authorized transactions are 

10 submitted to the acquirer in a format defined by, e.g., APACS 29 standard. The subscriber 
presents the credit/debit card information via the IVR 30 operated on the merchant's behalf. 
The card details are forwarded to the PCS 200, operated on merchant's behalf. 
[0050] The PCS 200 handles the APACS 30 interaction with the acquirer, and returns an 
authorization response message. The authorization response message is generated by the 

15 credit/debit card processing system and can be, e.g., one of the following outcomes: 

authorized, declined or referred. To the subscriber, decline and referred messages effectively 
have the same meaning because the available credit amount will not be increased. If the 
transaction is declined or referred, the subscriber is informed to contact the card issuer. If the 
transaction is authorized, the details of the MS ISDN and the available credit amount are 

20 passed to the EAS 40 queue for further processing (block 740). Once the credit/debit card 
authorization is performed on line, and authorized by the PCS 200, the IVR 30 passes this 
information to the CSS 50 for complete audit tracking within the CSS 50. In particular, the 
subscriber database 230 maintains, as described above, complete subscriber history of such 
transaction. 

25 

Scratch Card Activation 

[0051] The service provider generates, prints and distributes the scratch cards to retailers. 
The scratch cards are packed in a package. The retailer sells the scratch card to the 
subscriber. While in a distribution chain the scratch cards cannot be used on the system 1 
30 until they are activated. To activate the scratch card, the retailer has to contact the service 
provider. Upon providing necessary information {e.g., retailer's identification number, 
retailer's security code, and an identification number of the package), the service provider 
activates the scratch card. 
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[0052] The CSS 50 maintains detailed record about each scratch card in the scratch card 
database 240 (described above). In addition, the CSS 50 tracks all scratch cards usage to 
ensure that the scratch card cannot be used more than once. When the subscriber calls to 
increase the available credit amount, the CSS 50 confirms validity of the scratch card and no 
5 further authorization is required. In addition, the IVR 30 collects the scratch cards' records 
directly from the device 10, and passes these records to the CSS 50 for a validation matching. 
[0053] Once the scratch card is validated the IVR 30 terminates the call with the subscriber, 
then passes the MSISDN and credit update value to the DAS queue for further processing 
(block 720). The CSS 50 marks the scratch card as 'used* in the scratch card database 240, 
10 and then updates the subscriber database 230 to maintain the complete subscriber history. 

Device Barring/Disconnection 

[0054] The device 10 may be barred or completely disconnected. These operations may be 
done automatically by the IVR 30 or manually by the agents. When the agents access the 
15 IVR 30 support function, they can launch a background task within the IVR 30 that requests 
the CSS 50 to put an incoming call bar on the particular MSISDN. The CSS 50 interfaces 
with the NBAS 190 to issue the bar commands, thus preventing incoming SMS messages and 
telephony calls to and from the device 10. 

20 Agents of the Call Center 165 

[0055] The system 1 according to the present invention may function automatically using 
the IVR 30 (as described above) or manually with help of the service provider's agents 
(agents). The agents are positioned in the Call Center 165 and have a telephony interface 160 
and/or a workstation interface 170. The agents supplement the IVR 30 by performing similar 

25 processes. For instance, the agents may activate the device 10, increase the available credit 
amount, using the credit/debit card and/or the scratch card, and respond to general inquiries 
of the subscriber. 

[0056] As in the case of the IVR 30, the agents may transfer funds using the scratch and/or 
credit/debit cards. There is a potential for abuses by the agents within the Call Center 165 
30 because the agents are trusted personnel who require access to the processes in order to 

perform the necessary functions. Audit trails within the processes recognize this potential, 
and ensure that interfaces to these processes are secure and audited. Different levels of 
access will be required, as well as a personal identification number (PIN) protection for the 
agents. 
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[0057] The work queue model (described below) can also be used in case of the agents. 
The processes of the work queue model are the same as those within the IVR 30. The work 
queue model restricts the view of the tasks that perform the subprocesses to the agents 1 own 
input work queue, and the agents' own output work queue. The task performing the sub 
5 process has no knowledge of the sub processes that occur before itself. This therefore implies 
that different sub processes, running on different platforms, could all precede the task, 
provided that they have access fh, and share a common structure for placing data in the input 
work queue for the task. 

[0058] Figure 8 illustrates a process flow relating to the credit refresh operations that is 
10 similar to the one depicted in Figure 7, except that the agents of the Call Center 165 are being 
used instead of the IVR 30 to control the process. The agents place a work data into one or 
more queues (blocks 710, 720 and 750). This ensures integrity of the processes, being 
defined in only one place. In addition, it is necessary to use a queue management system that 
has a mufti user capability, as there may be multiple agent tasks writing to the input queues, 
15 as well as multiple occurrences of the subprocess task reading the input work queue and 
writing to the output work queue. 

[0059] The most suited system for implementing the queues using database tables, with full 
file and record locking mechanisms would be a relational database, such as from Oracle 
Corporation or Sybase. The IVR 30 can read and write from these databases, and the agents 1 

20 application would be written using, e.g., a conventual programming language, that also has 
read and write capabilities to these databases. All activities performed by the agents will be 
subject to stringent auditing. Every transaction processed through the work queues will be 
stamped with date/time and agent's logon identification 10 that placed the entry in the work 
queue, including the IVR 30 ports. 

25 [0060] The agents 1 application may be developed as a thin client 900 shown in Figure 9. 
The thin client 900 is the application deployment method that is generally considered the 
fastest to develop. The thin client 900 typically uses a web server 910 to connect to an 
information server 920. The application server 920 processes requests on behalf of the thin 
client 900 by accessing other information servers, and passes the responses back to the thin 

30 client 900. An interface for the thin client 900 can be developed using, e.g., Hyper Text 
Markup Language (HTML) or any other conventional programming languages. For the 
agents' application, the information server 920 already exists in the IVR 30. 
[0061] Brite Voice's Write 1 software environment with which the IVR 30 may be 
developed, has an extension that supports the web server 910. This is illustrated in Figure 10. 



The Write 1 software architecture model of a software bus 935 allows the web server 910 to 
use the software bus 935 to communicate with other components on the software bus 935. It 
permits the web server 910 to execute the same IVR 30 sub processes, access the same 
information, and allow the centralized management of the 'work queues'. 
[0062] The agent workstations can use a conventional web browser, e.g., Netscape® 
Version 4 from Netscape Corporation. Development may be written using, e.g., HTML and 
Write 1 Scenario Generation Language (SGL), accessing a database server 980. Requests 
from the web browser will be directed by the web server 910 to the web component 930 on 
the software bus 935, these in turn will run SGL subprocesses 940, which will in turn read 
from and write to the database 960. 

[0063] The above described system provides an arrangement that facilitates control of 
prepaid wireless devices. The arrangement simplifies the process by which a subscribers 
equipment can have its credit refreshed and have the rate schedule under which it operates 
updated. 

[0064] Several exemplary embodiments of the present invention are specifically illustrated 
and/or described herein. However, it will be appreciated that modifications and variations of 
the present invention are covered by the above teachings and within the purview of the 
appended claims without departing from the spirit and intended scope of the present 
invention. 
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